10장. AI 엔지니어링 아키텍처와 사용자 피드백

파운데이션 모델을 활용하는 AI 애플리케이션은 단순 API 호출에서 시작해 컨텍스트 보강 → 가드레일 → 라우터/게이트웨이 → 캐싱 → 에이전트 패턴 순으로 점진적으로 구성 요소를 추가하며 발전한다. 그 모든 단계에서 관찰 가능성(observability)은 나중에 덧붙이는 것이 아니라 설계 초기부터 핵심에 두어야 한다. 사용자 피드백은 제품 품질을 평가하는 신호이자 모델을 지속적으로 개선하는 독점 데이터 원천으로, AI 애플리케이션에서 그 중요성이 전통 소프트웨어보다 한층 높다.

학습 목표

이 장을 끝내면 다음을 할 수 있다.

• AI 애플리케이션 아키텍처의 5단계 진화 과정(컨텍스트 보강·가드레일·라우터/게이트웨이·캐싱·에이전트)을 이해하고 설계 상황에 맞게 적용하기
• 입력·출력 가드레일을 설계해 PII 유출·프롬프트 인젝션·품질 실패 위험을 완화하기
• 모델 라우터와 게이트웨이로 복잡한 멀티 모델 환경의 의도 분류·비용 관리·폴백을 구현하기
• 로그·지표·트레이스를 통한 관찰 가능성을 설계 초기부터 계획해 MTTD·MTTR·CFR을 추적하기
• 사용자 피드백(명시적·암시적)을 수집·분석하되 관대함·위치·최근성 편향을 인식해 해석하기

전체 흐름도

이 장의 핵심은 "단순 API 호출에서 시작해 아키텍처를 점진적으로 확장하고, 사용자 피드백을 선순환 데이터 플라이휠로 만드는 것"이다.

[ 사용자 요청 (Query) ]
      │
      ▼
[ 입력 가드레일 ]  ← PII 탐지·마스킹 / 프롬프트 인젝션 차단
      │
      ▼
[ 모델 라우터 ]    ← 의도 분류 → 최적 모델·솔루션으로 전달
      │
      ▼
[ 컨텍스트 보강 ]  ← RAG·외부 도구로 관련 정보 주입 (특성 공학)
      │
      ▼
[ 모델 게이트웨이 ] ← 통합 인터페이스·접근 제어·비용 관리·폴백
      │
      ▼
[ 모델 API 호출 ]  ← 서드파티(OpenAI·Google·Anthropic 등) 또는 자체 호스팅
      │
      ▼
[ 캐싱 계층 ]      ← 완전 일치(동일 요청 재사용) / 시맨틱(의미 유사 요청 재사용)
  (캐시 히트 시 여기서 반환)
      │
      ▼
[ 출력 가드레일 ]  ← 품질·보안 실패 탐지 → 재시도 / 병렬 호출 / 에스컬레이션
      │
      ▼
[ 에이전트 루프 ]  ← 미완료 시 추가 검색+재입력 반복 (순환 구조)
      │  (완료 시 탈출)
      ▼
[ 사용자 응답 반환 ]
      │
      │  관찰 가능성 (로그·지표·트레이스) ─ 전 구간 상시 계측
      ▼
[ 사용자 피드백 수집 ]
      │  명시적(좋아요/별점) + 암시적(행동 신호: 편집·재생성·조기 종료 등)
      ▼
[ 피드백 분석·편향 보정 ] ← 관대함·위치·길이·최근성 편향 인식
      │
      ▼
[ 모델 개선 (파인튜닝·RLHF) ]
      │
      └─────────────────────────────────┐
                                        ▼
                             [ 데이터 플라이휠 ]
                             (더 나은 모델 → 더 나은 응답 → 더 많은 사용자)

  아키텍처 5단계 진화:
  1단계 컨텍스트 보강 → 2단계 가드레일 → 3단계 라우터/게이트웨이
  → 4단계 캐싱 → 5단계 에이전트 패턴

0. 사전 필수 용어

참고 — 이 장은 아키텍처 설계 패턴과 피드백 시스템이 핵심이다. 개별 기법(RAG, 에이전트, 가드레일)의 상세 구현은 앞선 장들(5·6장)에서 다뤘고, 이 장은 그것들을 어떻게 조합하는지에 집중한다.

• 가드레일(Guardrail) — 입력 및 출력 단계에서 위험을 차단하거나 완화하는 보호 장치. 개인정보(PII) 탐지·유해 콘텐츠 필터·형식 검증 등을 포함한다.
• 모델 라우터(Router) — 질의의 의도나 유형을 분류해 가장 적합한 모델 또는 솔루션으로 전달하는 의도 분류기 역할의 구성 요소.
• 모델 게이트웨이(Gateway) — 여러 모델(외부 API + 자체 호스팅)에 통합 인터페이스를 제공하는 중간 계층. 접근 제어·비용 관리·폴백 정책을 담당한다.
• 관찰 가능성(Observability) — 시스템 외부 출력만으로 내부 상태를 추론할 수 있도록 로그·지표·트레이스를 설계하는 것. 단순 모니터링보다 적극적인 개념이다.
• 피드백 루프(Feedback Loop) — 사용자 반응이 모델 개선으로 이어지고 그 결과가 다시 사용자 경험에 영향을 주는 순환 구조. 잘 설계하면 데이터 플라이휠이 되지만, 방치하면 편향이 누적되는 퇴화 루프가 된다.
• 스코어러(Scorer) — 출력 가드레일에서 품질·보안을 평가하는 모델. 생성 모델보다 작고 빠르지만 AI 기반인 경우가 많다.
• 의도 분류기(Intent Classifier) — 라우터의 핵심 구성 요소. 사용자 질의의 의도를 예측해 적합한 솔루션으로 분기한다.
• 다음 행동 예측기(Next-Action Predictor) — 에이전트 환경에서 라우터가 다음에 어떤 도구(코드 인터프리터·검색 API 등)를 써야 할지 예측하는 역할.

1. AI 엔지니어링 아키텍처의 진화 — 단계적 확장 원칙

AI 애플리케이션을 처음부터 완전한 형태로 설계하려 하면 복잡성에 압도되기 쉽다. 저자가 제안하는 접근은 가장 단순한 형태에서 시작해 필요할 때마다 구성 요소를 하나씩 추가하는 점진적 확장이다.

가장 단순한 시작점 — 질의와 응답. 최소 형태의 AI 애플리케이션은 사용자 질의를 모델 API로 전달하고 응답을 반환하는 것이다. 컨텍스트 보강도 가드레일도 캐싱도 없다. 모델 API는 OpenAI·Google·Anthropic 같은 서드파티 API와 자체 호스팅 모델을 모두 가리킨다.

점진적 구성 요소 추가 순서. 이 장은 다음 다섯 단계 순서로 아키텍처를 발전시킨다.

1. 컨텍스트 보강으로 모델에 입력되는 정보를 풍부하게 한다.
2. 가드레일로 시스템과 사용자를 보호한다.
3. 라우터와 게이트웨이로 복잡성과 비용을 관리한다.
4. 캐싱으로 지연 시간과 비용을 최적화한다.
5. 에이전트 패턴으로 복잡한 로직을 지원한다.

주의 — 각 구성 요소를 추가할 때마다 시스템의 성능·안정성·속도가 향상될 수 있지만, 동시에 복잡성도 높아져 새로운 유형의 실패가 생긴다. 모든 구성 요소가 모든 애플리케이션에 필요한 것은 아니다.

2. 1단계 — 컨텍스트 보강

컨텍스트가 왜 중요한가. 컨텍스트 구성은 파운데이션 모델을 위한 특성 공학(feature engineering)과 같다. 모델이 출력을 생성하는 데 필요한 정보를 적절히 제공하는 것이다. ChatGPT, 클로드, 제미나이 같은 도구는 사용자가 파일을 업로드하거나 모델이 도구를 사용할 수 있게 허용한다.

보강 방법 두 가지.

• RAG처럼 텍스트·이미지·표 형식 데이터 검색을 통해 관련 정보를 가져온다.
• 웹 검색·날씨·이벤트 API 같은 외부 도구를 통해 모델이 실시간 정보를 수집하게 한다.

제공업체 간 차이. 모델마다 성능이 다른 것처럼, 컨텍스트 구성을 지원하는 방식도 제각각이다. 업로드 가능한 문서 유형과 수의 제한, 청크 크기, 검색 알고리즘, 병렬 함수 실행 가능 여부 등이 다르다. 전문 RAG 솔루션은 벡터 데이터베이스 용량이 허용하는 만큼 문서를 무제한으로 올릴 수 있지만, 범용 모델 API는 문서 수를 제한할 수 있다.

3. 2단계 — 가드레일 도입

가드레일은 입력 가드레일과 출력 가드레일로 나뉜다.

입력 가드레일 — 두 가지 위험 차단

PII 유출 방지. 외부 API로 개인정보가 유출되는 위험이다. 다음과 같은 경로로 발생한다.

• 직원이 회사 기밀이나 사용자 개인정보를 프롬프트에 복사해 서드파티 API로 전송하는 경우 (실제 사례: 삼성 직원이 서드파티 AI 서비스에 기밀정보를 입력해 유출한 사건)
• 애플리케이션 개발자가 회사 내부 정책을 시스템 프롬프트에 넣는 경우
• 도구가 내부 데이터베이스에서 개인정보를 가져와 컨텍스트에 추가하는 경우

민감한 데이터를 탐지해 [전화번호]·[ACCESS_TOKEN] 같은 플레이스홀더로 마스킹하고, PII 역방향 사전으로 응답의 플레이스홀더를 원래 정보로 복원한다. 일반적인 민감 데이터 유형:

• 개인정보 (주민번호, 전화번호, 계좌번호)
• 사람 얼굴
• 회사 지적 재산·기밀 정보와 관련된 특정 키워드

프롬프트 인젝션 차단. 공격자가 시스템을 망가뜨리려는 악성 프롬프트를 차단한다. 5장에서 다룬 방어 기법이 해당된다.

출력 가드레일 — 실패 탐지와 정책

품질 실패 (4장에서 다룬 내용):

• 예상한 출력 형식을 따르지 않는 잘못된 형식 응답 (예: 유효하지 않은 JSON)
• 모델이 만들어 낸 사실과 일치하지 않는 응답 (환각)
• 전반적으로 수준이 낮은 응답

보안 실패 (5장에서 다룬 내용):

• 유해한 응답 (인종차별·성적 콘텐츠·불법 활동)
• 개인정보나 민감한 정보가 포함된 응답
• 원격 도구나 코드 실행을 유발하는 응답
• 브랜드에 위험을 초래하는 잘못된 설명

보안 측정 시 보안 실패뿐 아니라 오거부율(false refusal rate) 도 확인해야 한다. 보안을 너무 강하게 적용하면 정상 요청까지 차단해 사용자를 방해할 수 있다.

처리 방법 세 가지:

(a) 재시도 — AI는 확률적이므로 같은 질의를 다시 하면 다른 결과를 얻을 수 있다. 단, 지연 시간과 비용이 증가한다.

(b) 병렬 호출 — 첫 번째 결과를 기다리지 않고 같은 질의를 모델에 동시에 두 번 보내고 더 나은 것을 선택한다. API 호출 수는 늘지만 지연 시간은 관리 가능한 수준으로 유지된다.

(c) 사람에게 에스컬레이션 — 특정 문구가 포함된 질의, 감정 분석 모델이 분노를 감지하는 경우, 대화가 일정 턴 수를 넘는 경우 상담원에게 연결한다.

가드레일 구현 트레이드오프. 가드레일은 지연 시간을 늘린다. 일부 팀은 지연 시간을 우선시해 가드레일을 포기하기도 하나, 초창기 도입자들은 이를 끔찍한 결과를 낳는다고 경고했다. 스트림 완성 모드에서는 새 토큰이 생성되는 즉시 전달되므로 출력 가드레일이 차단 결정을 내리기 전에 안전하지 않은 응답이 부분적으로 전달될 수 있다.

서드파티 API를 사용하면 제공업체가 다양한 가드레일을 기본으로 제공하므로 직접 구현할 부분이 줄어든다. 자체 호스팅 모델은 요청을 외부로 보낼 필요가 없어 입력 가드레일 일부가 불필요해진다.

주요 가드레일 솔루션 (책 집필 시점 기준):

• 메타의 Purple Llama (퍼플 라마)
• 엔비디아의 NeMo Guardrails (네모 가드레일)
• 애저의 PyRIT
• 애저의 AI 콘텐츠 필터
• Perspective API
• OpenAI의 콘텐츠 조정 API

4. 3단계 — 모델 라우터와 게이트웨이

라우터 — 질의를 최적 솔루션으로 보낸다

의도 분류기의 세 가지 역할:

(a) 의도 분류 — 질의 유형별로 적합한 솔루션으로 분기한다.

• 비밀번호 재설정 요청 → FAQ 페이지
• 청구 오류 수정 → 상담원 연결
• 기술 문제 해결 → 특화 챗봇

범위 밖 질의는 API 호출을 낭비하지 않고 "저는 챗봇이라 투표할 수 없습니다. 제품에 대한 질문이 있으시면 도와드리겠습니다"처럼 미리 준비된 응답으로 정중하게 거절한다.

(b) 모호한 질의 명확화 — Freezing이라는 질의에 "계정을 정지하고 싶으신 건가요, 아니면 날씨 얘기를 하시는 건가요?"처럼 묻는다.

(c) 다음 행동 예측 — 에이전트 환경에서 코드 인터프리터를 쓸지 검색 API를 쓸지 결정한다. 메모리 계층 어느 부분에서 정보를 가져와야 할지도 예측한다.

라우터 구현 원칙. 라우터는 빠르고 저렴해야 한다. 여러 라우터를 사용해도 지연 시간과 비용이 크게 늘어나지 않아야 하기 때문이다. 책 집필 시점 기준 많은 팀이 GPT-2, BERT, 라마 7B 같은 작은 언어 모델을 의도 분류기로 활용하고, 처음부터 직접 만들기도 한다.

컨텍스트 한계가 다른 모델로 라우팅할 때 컨텍스트를 잘라내거나, 더 큰 컨텍스트 한계를 가진 모델로 라우팅할 수 있다.

일반적인 흐름: 라우팅 → 검색 → 생성 → 스코어링(평가)

게이트웨이 — 다양한 모델의 통합 인터페이스

게이트웨이의 가장 단순한 형태는 통합 래퍼다. 다음 코드 예제는 구현 방식을 보여준다.

import google.generativeai as genai
import openai

def openai_model(input_data, model_name, max_tokens):
    openai.api_key = os.environ["OPENAI_API_KEY"]
    response = openai.Completion.create(
        engine=model_name,
        prompt=input_data,
        max_tokens=max_tokens
    )
    return {"response": response.choices[0].text.strip()}

def gemini_model(input_data, model_name, max_tokens):
    genai.configure(api_key=os.environ["GOOGLE_API_KEY"])
    model = genai.GenerativeModel(model_name=model_name)
    response = model.generate_content(input_data, max_tokens=max_tokens)
    return {"response": response["choices"][0]["message"]["content"]}

@app.route('/model', methods=['POST'])
def model_gateway():
    data = request.get_json()
    model_type = data.get("model_type")
    model_name = data.get("model_name")
    input_data = data.get("input_data")
    max_tokens = data.get("max_tokens")
    if model_type == "openai":
        result = openai_model(input_data, model_name, max_tokens)
    elif model_type == "gemini":
        result = gemini_model(input_data, model_name, max_tokens)
    return jsonify(result)

게이트웨이의 주요 기능:

(a) 통합 인터페이스 — 모델 API가 변경되더라도 게이트웨이만 업데이트하면 된다. (b) 접근 제어 — 세분화된 접근 권한을 중앙에서 관리한다. (c) 비용 관리 — API 호출 사용량을 모니터링하고 제한한다. (d) 폴백 정책 — API 실패 시 대체 모델로 요청을 보내거나 재시도한다.

모든 요청이 게이트웨이를 통과하므로 로드 밸런싱·로깅·분석 구현에도 적합한 지점이다. 일부 게이트웨이는 캐싱이나 가드레일 기능도 제공한다.

즉시 사용 가능한 게이트웨이 (책 집필 시점 기준): Portkey AI 게이트웨이, MLflow AI 게이트웨이, 웰스심플의 LLM 게이트웨이, 트루파운드리, Kong, 클라우드플레어 등

NOTE — 도구 게이트웨이 같은 비슷한 추상화 계층도 다양한 도구에 접근하는 데 유용할 수 있다. 집필 시점에는 아직 일반적인 패턴이 아니었다.

5. 4단계 — 캐싱으로 지연 시간 최적화

캐싱은 AI 애플리케이션에서 지연 시간과 비용을 줄이는 가장 검증된 방법이다. 시스템 캐싱에는 완전 일치 캐싱과 시맨틱 캐싱이 있다.

참고 — KV 캐시와 프롬프트 캐시는 모델 API 제공업체가 구현하는 추론 수준의 캐싱(9장)이고, 이 절에서 다루는 것은 시스템 수준의 애플리케이션 캐싱이다.

완전 일치 캐싱(Exact-match Caching)

정확히 같은 형태의 요청에만 캐시된 항목을 사용한다. 임베딩 기반 검색에서도 중복 벡터 검색을 피하기 위해 사용된다.

특히 효과적인 경우: - 생각의 사슬(CoT)처럼 여러 단계를 포함하는 질의 - 벡터 검색·SQL 실행·웹 검색처럼 시간이 오래 걸리는 동작이 포함된 질의

저장 방식: 빠른 검색을 위한 인메모리 저장소와 PostgreSQL·Redis 같은 영속 저장소를 계층화한다.

제거 정책: LRU(가장 오래 사용되지 않은 것 제거)·LFU(가장 적게 사용된 것 제거)·FIFO(선입선출)

캐싱 결정: "최근 주문 상태는?" 같은 사용자별 질의나 "오늘 날씨?" 같은 시간 민감 질의는 캐시에 저장하지 않는 것이 좋다. 별도의 분류기로 저장 여부를 예측하는 팀도 있다.

보안 위험: 사용자 X의 개인정보가 포함된 응답을 일반 질의 응답으로 잘못 캐시하면, 나중에 사용자 Y가 같은 질의를 할 때 X의 정보가 노출될 수 있다.

시맨틱 캐싱(Semantic Caching)

의미는 같지만 표현이 다른 질의를 동일하게 처리한다.

작동 방식: 1. 질의마다 임베딩 모델로 임베딩 생성 2. 벡터 검색으로 가장 유사도 점수가 높은 캐시된 임베딩을 찾는다 3. 유사도 X가 임계값을 초과하면 캐시된 결과를 반환한다. 그렇지 않으면 현재 질의를 처리하고 결과와 임베딩을 함께 캐시에 저장한다.

한계 — 구성 요소가 망가지기 쉬운 이유: - 좋은 품질의 임베딩 필요 - 안정적인 벡터 검색 필요 - 신뢰할 수 있는 유사도 측정 필요 - 적절한 유사도 임계값 설정이 까다로워 시행착오가 많이 필요

그래도 캐시 적중률이 높은 시나리오에서는 여전히 가치가 있다.

6. 5단계 — 에이전트 패턴으로 복잡한 로직 지원

단순 순차 흐름의 한계를 넘으려면 루프·병렬 실행·조건부 분기가 필요하다. 6장에서 다룬 에이전트 패턴이 이를 가능하게 한다.

피드백 루프 구조. 모델 출력이 작업을 완료하지 못했다고 판단하면, 시스템이 추가 검색을 수행하고 원래 응답과 새 컨텍스트를 합쳐 같은 모델이나 다른 모델에 다시 넣는다. 이 루프가 아키텍처를 순환 구조로 만든다.

쓰기 작업 — 능력 확장과 위험 증가의 트레이드오프. 이메일 발송·주문 업데이트·은행 이체 같은 쓰기 작업을 통해 시스템이 환경을 직접 변경할 수 있게 된다. 쓰기 작업은 시스템 능력을 대폭 향상시키지만 동시에 훨씬 더 많은 위험에 노출시킨다. 쓰기 작업 접근 권한 부여는 최대한 신중하게 이루어져야 한다.

7. 모니터링과 관찰 가능성

관찰 가능성은 나중에 추가하는 것이 아니라 처음 설계할 때부터 핵심에 두어야 한다.

모니터링 vs 관찰 가능성의 차이:

• 모니터링 — 시스템의 외부 출력을 지속적으로 관찰해서 내부에서 문제가 발생하는 시점을 알아내는 행위. 그 출력만으로 문제의 원인을 파악할 수 있다는 보장은 없다.
• 관찰 가능성 — 시스템의 외부 출력에 대한 지식으로 내부 상태를 추론할 수 있다는 더 강력한 가정. 관찰 가능한 시스템에서는 새 코드를 배포하지 않아도 로그와 지표만으로 문제 원인을 찾을 수 있어야 한다.

모니터링의 목표. 위험 감소(애플리케이션 실패·보안 공격·드리프트)와 기회 발견(성능 개선·비용 절감·책임 명확화)이다.

DevOps 3대 지표:

• MTTD(Mean Time To Detection) — 문제가 생겼을 때 감지하는 데 걸리는 시간
• MTTR(Mean Time To Response) — 감지 후 해결에 걸리는 시간
• CFR(Change Failure Rate) — 수정이나 롤백이 필요한 실패를 일으키는 변경·배포 비율. CFR을 모른다면 플랫폼을 더 관찰 가능하게 재설계해야 할 때다.

추적해야 할 핵심 지표:

• 형식 실패 — 유효하지 않은 JSON 빈도, 수정 가능한 오류 비율
• 생성 품질 — 일관성·간결성·창의성·긍정성 (AI 평가자로 계산 가능)
• 안전 지표 — 유해성, PII 탐지, 가드레일 개입 빈도, 응답 거부율
• 대화 신호 — 생성 중단 빈도, 대화당 턴 수, 입출력 토큰 수, 토큰 분포
• 지연 시간 — TTFT(첫 토큰까지), TPOT(출력 토큰당), 총 지연 시간
• 비용 — 질의 수, 초당 토큰 수(TPS), API 속도 제한 근접 여부

이 지표들을 DAU·세션 지속 시간 같은 비즈니스 핵심 지표와 상관분석하면 무엇을 최적화할지 결정하는 데 도움이 된다.

지표를 계산할 때는 사용자, 릴리즈 버전, 프롬프트/체인 버전, 타입, 시간 같은 기준으로 세분화할 수 있는지 확인해야 한다.

로그와 트레이스.

• 로그 — 추기만 가능한 개별 이벤트 기록. 로깅의 일반적인 원칙은 모든 것을 로깅하는 것이다. 모델 API 엔드포인트·모델 이름·샘플링 설정·프롬프트 템플릿·사용자 질의·최종 프롬프트·출력·중간 출력·도구 호출 여부·단계별 시작/종료 시간을 포함한다. 로그를 수동으로 처리하기는 불가능에 가깝지만, 매일 운영 데이터를 수동으로 살펴보는 것은 유용하다 — 개발자들이 더 많은 데이터와 상호작용하면서 좋은 출력과 나쁜 출력에 대한 인식이 바뀌고 프롬프트를 개선할 수 있다 (Shankar et al., 2024).

• 트레이스 — 관련 이벤트들을 하나로 연결해 처음부터 끝까지의 완전한 타임라인을 보여준다. 사용자 질의 시점부터 최종 응답까지 어떤 문서를 검색했는지, 모델에 보낸 최종 프롬프트가 무엇인지, 각 단계에 걸린 시간과 비용까지 포함해야 한다. 어느 단계에서 문제가 발생했는지(질의 처리·검색·모델 생성) 정확히 파악할 수 있게 한다. LangSmith는 요청 트레이스를 시각화하는 대표적 도구다.

드리프트 감지 — 세 가지 유형:

(a) 시스템 프롬프트 변경 — 템플릿 업데이트, 동료의 오타 수정 등으로 의도치 않게 변경될 수 있다. 버전 관리로 감지 가능하다.

(b) 사용자 행동 변화 — 사용자들이 더 좋은 결과를 얻기 위해 질의 방식을 바꾼다. 예를 들어, 구글 검색에서 더 좋은 결과를 얻는 방법을 배운 것처럼. 시계열 지표로 추이를 관찰한다.

(c) 기반 모델 변경 — API 버전이 같아도 내부 모델이 업데이트될 수 있다. Chen 등의 연구(2023, 논문 발표 당시 기준)는 동일 시리즈 모델의 버전 차이(3월판과 6월판)에서 벤치마크 점수가 눈에 띄게 달라짐을 관찰했다. Voiceflow도 동일 계열 모델의 구버전(0301)에서 신버전(1106)으로 교체했을 때 성능이 10% 저하됐다고 보고했다 (책 집필 당시 사례). 주기적으로 동일 벤치마크를 실행해 변화를 탐지해야 한다.

8. AI 파이프라인 오케스트레이션

애플리케이션이 복잡해질수록 여러 모델·데이터베이스·도구의 상호작용을 정의하는 오케스트레이터가 필요해진다.

오케스트레이터의 두 단계:

• 구성 요소 정의 — 어떤 모델·데이터 소스·도구를 쓸지 선언한다. 모델 게이트웨이를 사용하면 모델 추가가 더 쉽다.
• 체이닝(파이프라이닝) — 사용자 질의 수신부터 작업 완료까지의 단계 순서를 정의한다.

전형적인 흐름: ① 원본 질의 처리 → ② 관련 데이터 검색 → ③ 프롬프트 구성 → ④ 모델 응답 생성 → ⑤ 응답 평가 → ⑥ 반환 또는 에스컬레이션

병렬 처리 활용. 지연 시간 요구가 엄격한 애플리케이션에서는 독립적인 구성 요소(라우팅과 PII 제거 등)를 동시에 처리한다.

오케스트레이터 선택 기준 세 가지:

(a) 통합·확장성 — 현재 및 미래에 사용할 구성 요소를 지원하는지. 특정 구성 요소를 지원하지 않는다면 변경이 얼마나 어려운가?

(b) 복잡한 파이프라인 지원 — 분기·병렬 처리·오류 처리 같은 고급 기능을 지원하는지.

(c) 사용 편의성·성능·확장성 — 직관적인 API, 포괄적 문서, 강력한 커뮤니티 지원. 숨겨진 API 호출이나 불필요한 지연을 일으키지 않는지.

주의 — 프로젝트 초반에는 도구 없이 애플리케이션을 만들어 보는 것이 좋다. 오케스트레이터는 핵심 세부 사항을 추상화해 디버깅을 어렵게 만들 수 있다.

주요 AI 오케스트레이션 도구 (책 집필 시점 기준): LangChain, LlamaIndex, Flowise, Langflow, Haystack

9. 사용자 피드백 — AI 애플리케이션의 핵심 자산

피드백이 AI에서 더 중요한 이유. 사용자 피드백은 독점 데이터이고, 독점 데이터는 경쟁 우위의 원천이다. 빨리 출시해 초기 사용자를 확보한 제품은 피드백 데이터를 쌓아가며 모델을 계속 개선해 경쟁자가 따라잡기 어렵게 만든다(데이터 플라이휠). 데이터가 점점 부족해지면서 독점 데이터의 가치는 더 높아지고 있다.

사용자 피드백이 곧 사용자 데이터이므로, 수집 및 활용 시 프라이버시를 보호하고 사용 방식을 투명하게 공개해야 한다.

참고 — 오픈 소스 애플리케이션의 주요 단점 중 하나는 사용자 피드백 수집이 훨씬 어렵다는 것이다. 사용자들이 직접 배포하면 개발자는 사용 방식을 전혀 알 수 없다.

대화형 피드백 활용: 대화에서 추출한 사용자 피드백은 세 가지로 활용할 수 있다. - 평가 — 애플리케이션을 모니터링할 지표 도출 - 개발 — 향후 모델 학습이나 개발 방향 안내 - 개인화 — 각 사용자에게 맞게 애플리케이션을 개인화

명시적 피드백과 암시적 피드백.

• 명시적 피드백 — 좋아요/싫어요·별점·"문제가 해결되었나요?" 같은 직접 요청에 대한 응답. 어떤 애플리케이션에서도 방식이 거의 비슷하고 해석이 쉽다. 단점: 사용자에게 추가 수고를 요구하므로 특히 사용자 수가 적은 애플리케이션에서 드물게 나타날 수 있다. 불만족한 사용자가 불평할 가능성이 높아 실제보다 더 부정적으로 보일 수 있다.

• 암시적 피드백 — 추천 제품 구매 여부, 생성 조기 종료, 재생성 선택, 대화 삭제 등 행동에서 추론. 명시적 피드백보다 훨씬 풍부하지만 노이즈도 많다. 예를 들어 대화 공유는 긍정일 수도 부정일 수도 있다.

자연어 피드백 신호

대화 내용과 패턴에서 추출하는 신호다. 자연어 피드백은 챗GPT가 나오기 몇 년 전부터 연구 분야였다.

(a) 조기 종료 — 생성 중단, 앱 종료, 에이전트 방치. 대화가 잘 이뤄지지 않을 가능성.

(b) 오류 교정 — "아니요, 내 말은...", "다시 확인해 보세요", "출처를 보여주세요"로 시작하거나 요청을 다른 방식으로 재표현. 모델의 응답이 벗나갔을 가능성.

(c) 직접 편집 — 사용자가 생성된 코드·텍스트를 수정. 가장 강한 부정 신호이자 귀중한 선호 데이터. 원래 응답 = 비선호, 편집본 = 선호.

(d) 감정 표현 — 불평 없이 "..."처럼 부정적인 감정(좌절·실망·조롱)을 표현. 대화 전반의 감정 추이 분석으로 시스템 성능 통찰 가능.

FITS 데이터셋의 자연어 피드백 분류 (Xu et al., 2022 / Yuan et al., 2023):

자연어 피드백 데이터셋을 자동 클러스터링한 결과 8개 그룹으로 분류됐다.

기타 대화형 피드백

재생성. 첫 응답 불만족 또는 다른 옵션 비교 목적으로 사용. 이미지·이야기 생성 같은 창의적 요청에서 특히 흔하다. 재생성 후 "이 응답이 이전보다 더 좋았나요, 나빴나요?"처럼 비교 피드백을 직접 요청하면 선호도 파인튜닝 데이터로 활용할 수 있다. 사용량 기반 과금 앱에서는 추가 비용을 내면서 재생성한다는 것 자체가 첫 응답에 실제로 불만족했다는 더 강한 신호다.

대화 관리. 삭제(강한 부정 신호), 이름 변경(콘텐츠는 좋지만 제목 불만), 공유·북마크(맥락에 따라 해석 다름).

대화 길이. AI 친구 앱에서 긴 대화 = 참여도 높음. 고객 지원 챗봇에서 긴 대화 = 비효율. 애플리케이션 목적에 따라 해석이 다르다.

대화 다양성. 대화는 길지만 봇이 몇 마디 말만 계속 반복한다면 사용자는 루프에 갇혔을 수 있다.

10. 피드백 수집 시점과 방법

피드백 수집 타이밍 네 가지:

(a) 처음 시작할 때 — 신규 가입 시 초기 행동 보정에 활용. 얼굴 인식·음성 어시스턴트처럼 보정이 필수인 경우도 있다. 다른 애플리케이션에서는 온보딩 마찰을 줄이기 위해 선택 사항으로 하는 것이 좋다.

(b) 문제가 생겼을 때 — 환각·부적절한 응답·긴 지연 발생 시 항상 피드백 옵션 제공. 이상적으로는 모델이 실수를 해도 사용자들이 여전히 작업을 완수할 수 있어야 한다. 이미지 생성의 인페인팅(inpainting) 기능이 좋은 예다 — 사용자가 원하는 것과 다른 부분만 선택해 프롬프트로 수정하면 개발자에게도 고품질 피드백이 된다.

(c) 모델 신뢰도가 낮을 때 — 두 가지 요약을 나란히 보여주고 선호하는 것을 선택하게 한다. 이는 선호도 파인튜닝 데이터로 활용 가능하다. 전체 응답을 나란히 보여주는 방식과 부분 응답만 보여주는 방식(구글 제미나이 방식) 중 어느 쪽이 더 신뢰할 수 있는 피드백을 제공하는지는 아직 명확하지 않다.

(d) 사용자 여정 전반 — 항상 피드백을 남길 수 있는 선택지를 제공하되, 흐름을 방해하지 않아야 한다.

좋은 피드백 설계 원칙. 사용자 워크플로에 자연스럽게 녹아들어야 하고, 추가 수고 없이 쉽게 줄 수 있어야 한다.

• 미드저니(Midjourney) — U1~U4(업스케일)·V1~V4(변형)·재생성 선택지는 피드백 수집을 워크플로 안에 내장한 우수 사례. 업스케일 = 강한 긍정, 변형 = 약한 긍정, 재생성 = 불만족 신호.
• GitHub Copilot — 탭 수락/타이핑으로 무시가 자연스러운 피드백. 사용자의 일상 워크플로에 완전히 내장된 형태. ChatGPT·클로드 같은 독립형 앱은 GitHub Copilot처럼 기존 도구에 내장되지 않아 고품질 피드백 수집이 어렵다.

피드백의 공개 vs 비공개. 비공개 환경에서 사용자들은 더 솔직해지는 경향이 있다. X(구 트위터)가 좋아요를 비공개로 전환한 후 좋아요 수가 크게 늘었다. 단, 비공개 신호는 설명 가능성(explainability)을 감소시킨다.

피드백 설계의 함정. 애매한 설계는 노이즈가 많은 피드백을 만든다. 실제 사례: 루마(Luma) 피드백 폼에서 이모지 순서가 반대로 배치되어(1점에 화난 이모지가 5점 자리에 배치됨) 긍정적인 리뷰를 남기면서 실수로 1점 이모지를 선택한 사용자가 생겼다. 사용자를 헷갈리게 하는 설계는 피해야 한다.

피드백 요청 비율 조절. 사용자가 많다면 한 번에 1%에게만 요청을 보내 대부분의 사용자 경험을 방해하지 않으면서 충분한 피드백을 수집할 수 있다. 단, 비율이 작을수록 피드백 편향 위험이 커진다.

11. 피드백의 한계와 편향

관대함 편향(Leniency Bias). 갈등 회피·친절 의무감·가장 쉬운 선택이기 때문에 실제보다 더 긍정적으로 평가하는 경향. 2015년 우버 운전기사 평균 평점이 4.8점이었고, 4.6점 미만은 퇴출 위험이 됐다. 완화: 숫자 대신 서술형 선택지 제공 ("이 기사와 다시는 매칭하지 마세요" 등).

무작위성. 긴 응답 두 개를 나란히 보여줄 때 사용자가 둘 다 읽기 싫어 아무거나 클릭하는 경우. 완화: 응답의 일부분만 보여주고 읽고 싶은 것을 클릭하게 한다.

위치 편향. 두 번째 제안보다 첫 번째 제안을 클릭할 가능성이 높다. 완화: 선택지 위치를 무작위로 바꾸거나 위치별 성공률을 보정하는 모델을 만든다.

선호도 편향. 더 긴 응답을 정확도에 무관하게 선호하는 길이 편향, 마지막에 본 응답을 선호하는 최근성 편향(recency bias)이 있다. 완화: 보정 모델 사용.

퇴화 피드백 루프(Degenerate Feedback Loop). 예측 자체가 피드백에 영향을 주고, 피드백이 다시 모델을 바꾸면서 초기 편향이 누적되는 구조. 동영상 추천에서 순위가 높은 것이 더 많은 클릭을 얻고 그 클릭이 다시 순위를 높이는 '노출 편향'이 전형적 예다.

퇴화 피드백 루프는 제품의 초점과 사용자층 자체를 바꿀 수 있다. 예: 초기 사용자 피드백이 고양이 사진을 좋아한다면, 시스템이 고양이 사진을 더 생성 → 고양이 애호가 유입 → 더 많은 고양이 사진 피드백 → 앱이 고양이 천국이 됨. 같은 원리로 인종차별·성차별·선정적 콘텐츠 선호 같은 편향도 키워질 수 있다.

아첨(Sycophancy) 위험. 사용자 피드백으로 모델을 학습시키면 모델이 정확한 응답보다 사용자가 듣고 싶은 응답을 하도록 학습될 수 있다. Sharma 등의 연구(2023)는 사람 피드백으로 학습된 AI 모델이 사용자의 견해와 일치하는 응답을 제시할 가능성이 높아진다고 밝혔다.

사용자 피드백의 근본적 한계. 사용자에게 보여준 것에 대한 피드백만 얻을 수 있다. 피드백을 제품에 반영하기 전에 그 한계와 잠재적 영향을 이해해야 한다.

핵심 개념 정리

실무 체크리스트

• [ ] 아키텍처를 단번에 완성하려 하지 않고 최소 형태에서 시작해 필요한 구성 요소만 추가했는가?
• [ ] 입력 가드레일에 PII 탐지와 마스킹/언마스킹 처리(역방향 사전)가 있는가?
• [ ] 출력 가드레일에 오거부율(false refusal rate)도 함께 측정하는가?
• [ ] 출력 가드레일에 재시도 정책과 에스컬레이션 조건이 명시되어 있는가?
• [ ] 스트리밍 모드에서 출력 가드레일 제약을 인식하고 대응 방안을 마련했는가?
• [ ] 라우터가 범위 밖 질의를 우아하게 거절하고 모호한 질의를 명확화 요청하는가?
• [ ] 캐시 설계에서 사용자별/시간 민감 질의를 캐시 제외 처리했는가?
• [ ] 에이전트 패턴의 쓰기 작업 권한을 최소 권한 원칙으로 부여했는가?
• [ ] 관찰 가능성(MTTD·MTTR·CFR)을 처음 설계 단계부터 포함했는가?
• [ ] 드리프트 감지(시스템 프롬프트 변경·사용자 행동 변화·기반 모델 변경)를 추적하는가?
• [ ] 피드백 수집이 사용자 워크플로를 방해하지 않고 자연스럽게 녹아드는가?
• [ ] 피드백 편향(관대함·위치·최근성·길이)을 인식하고 해석 시 보정하는가?
• [ ] 퇴화 피드백 루프 발생 가능성을 점검하고 다양성 확보 전략이 있는가?
• [ ] 아첨 위험을 방지하기 위해 피드백을 직접 학습 신호로 쓰기 전 독립 검증 단계가 있는가?

연습문제

1. 분석. 시맨틱 캐싱이 "구성 요소가 망가지기 쉽다"고 저자가 표현하는 이유를 임베딩·벡터 검색·유사도 임계값 세 측면에서 설명하고, 각각의 실패가 최종 응답에 어떤 영향을 미치는지 논하라.

2. 설계. 고객 지원 챗봇을 위한 라우터를 설계하라. 의도 분류 카테고리 최소 5개와 각 카테고리의 처리 방식(FAQ·특화 모델·상담원 연결·거절 등)을 구체적으로 정의하라.

3. 비교. 입력 가드레일과 출력 가드레일을 서드파티 API 사용 환경과 자체 호스팅 환경에서 각각 어떻게 다르게 설계해야 하는지 비교하라. 스트리밍 모드의 공통 제약도 포함하라.

4. 적용. 퇴화 피드백 루프의 세 가지 구체적 시나리오(노출 편향·편향 증폭·아첨 학습)를 설명하고, 각 시나리오를 완화하는 기술적 방법을 제안하라.

5. 종합. 이 장에서 제안하는 5단계 아키텍처 진화를 따를 때, 각 단계에서 새로 생기는 실패 모드 한 가지씩을 식별하고, 그 실패를 감지하기 위해 어떤 지표와 로그를 추가해야 하는지 설명하라.

최신 동향 (2026-05 기준)

최신 동향 (검증 2026-05-21) — 아키텍처 구성요소가 빠르게 표준 도구로 정착했다. 책의 5단계 진화 틀은 유효하되 아래 도구를 함께 보라. (개념·흐름은 책 내용 유효)

• AI 파이프라인 관찰 가능성. LLM 애플리케이션 전용 트레이싱·평가·모니터링 도구가 정착했다. LangSmith, Langfuse, Helicone, OpenLLMetry 같은 도구가 프로덕션 관찰 가능성의 사실상 표준으로 자리잡고 있다.

• 모델 게이트웨이. 멀티 프로바이더(OpenAI·Anthropic 등)를 단일 인터페이스로 추상화하는 LiteLLM 같은 게이트웨이가 라우팅·폴백의 사실상 표준이 됐다.

• 가드레일. 입출력 검증·정책 적용을 위한 Guardrails AI 같은 프레임워크가 production 안전장치로 널리 쓰인다.

• 시맨틱 캐싱. 의미가 비슷한 질의의 응답을 재사용해 비용·지연을 줄이는 GPTCache 패턴이 보편화됐다.

• 에이전트 설계 패턴. 단순·검증 가능한 패턴 우선 원칙을 정리한 Building Effective Agents가 널리 참조된다.

부록 A. 용어 사전

부록 B. 핵심 비교표

입력 가드레일 vs 출력 가드레일

명시적 피드백 vs 암시적 피드백

완전 일치 캐싱 vs 시맨틱 캐싱

부록 C. 추천 참고 자료

부록 D. 연습문제 풀이

1. (세 구성 요소의 독립적 실패가 연쇄됨) 임베딩 모델이 동일 의미를 다른 벡터로 표현하면 같은 질의가 캐시 미스로 처리된다. 벡터 검색이 불안정하면 임계값 이하의 무관한 캐시 항목이 반환될 수 있다. 유사도 임계값이 너무 낮으면 의미가 다른 질의의 응답이 잘못 재사용되어 오답이 그대로 사용자에게 전달된다. 세 구성 요소 중 하나라도 오동작하면 캐싱이 오히려 정확도를 낮추는 원인이 되므로, 저자는 "구성 요소가 망가지기 쉽다"고 표현했다.

2. (의도 카테고리 5개와 처리 방식 매핑) 고객 지원 챗봇 라우터의 의도 분류 예시:

라우터는 빠르고 저렴해야 하므로 BERT, DistilBERT 같은 소규모 분류기를 의도 분류기로 사용하고, 명확화가 필요한 경우에만 추가 대화를 진행한다.

1. (환경에 따라 필요한 가드레일의 범위가 달라짐) 서드파티 API 환경에서는 입력 가드레일이 필수적이다. 프롬프트에 포함된 PII가 외부 API로 그대로 전송되므로 탐지·마스킹·언마스킹 파이프라인을 직접 구현해야 한다. 출력 가드레일은 서드파티 API가 기본 가드레일을 제공하므로 일부 중복 구현을 줄일 수 있다. 자체 호스팅 환경에서는 요청이 내부 인프라에서만 처리되므로 입력 가드레일의 PII 유출 위험이 감소하지만, 출력 품질과 보안 검사는 전적으로 자체 구현해야 한다. 스트리밍 모드의 경우 두 환경 모두에서 부분 응답이 전달된 후 차단 결정이 내려지는 지연 문제는 공통 제약이다.

2. (세 시나리오와 완화 방법) 첫째, 노출 편향: 추천 시스템에서 상위 노출 항목이 더 많은 클릭을 받고, 그 클릭 데이터가 다시 해당 항목의 순위를 높이는 순환이 발생한다. 완화 방법은 역성향 점수(Inverse Propensity Score)로 노출 확률을 보정하거나, 일부 요청에 무작위 추천을 섞어 탐색 데이터를 수집하는 것이다. 둘째, 편향 증폭: 초기 학습 데이터에 포함된 편향이 모델 예측에 반영되고, 그 예측 기반의 사용자 행동이 다시 학습 데이터가 되어 편향이 누적된다. 완화 방법은 반사실(counterfactual) 데이터 수집과 주기적인 편향 감사(bias audit)다. 셋째, 아첨 학습: 사용자 피드백으로 파인튜닝하면 모델이 정확한 응답보다 사용자가 듣고 싶은 응답을 선호하는 방향으로 학습된다. 완화 방법은 피드백을 직접 학습 신호로 쓰는 대신 독립 평가 모델로 품질을 검증한 뒤 선별해 학습 데이터로 활용하는 것이다.

3. (단계별 신규 실패 모드와 감지 지표) 각 단계에서 추가되는 대표 실패 모드: